Field of the Invention
Embodiments of the present invention relate to applications and the World Wide Web.
Background Art
A web browser is a software application that allows a user to view or download content that is available on a network, such as on a website on the World Wide Web. Content may include text, files, images, audio, video and personal communications. A browser may also allow a user to enter, upload, or execute content. Browsers run on personal computers and mobile devices. Commonly used browsers may presently include, for example, FIREFOX, INTERNET EXPLORER, SAFARI, and OPERA.
Browsers may use a number of protocols and standards to obtain or manage content flow. Most browsers primarily use hypertext transfer protocol (HTTP) to fetch content and webpages. Webpages are located using a uniform resource locator (URL), which identifies where the webpage may be found. Webpages may be retrieved using the IP address of the computer holding the webpage content. In order to be more memorable and human friendly, an IP address or hierarchy may be represented by a hostname (such as www.google.com). A hostname is a domain name that has one or more associated IP addresses. A hostname request is a request to navigate to a webpage using a URL hostname. For example, a hostname request may include a user clicking on a link on a web page or typing a hostname in a URL bar. Hostnames and other information associated with domain names may be resolved or translated to IP addresses using the Domain Name System (DNS). This DNS resolution system is sometimes referred to as the “phone book” for the Internet.
DNS resolution requires either looking in a local computer cache or querying a set of DNS servers over the network. A request for DNS resolution may also be known as a DNS lookup call. DNS utilizes authoritative name servers to help map domain names to IP addresses in order to avoid having all the information in a single, central DNS server. These and other intermediate name servers may cache DNS resolution information to shorten DNS resolution times.
For example, FIG. 1 illustrates an exemplary system 100 that performs DNS resolution. When network traffic is required, UDP packets are sent to a DNS resolver, and eventually a UDP response is provided. DNS resolutions may exist in a local cache, such as operating system DNS cache 110. If not, the next resolver is commonly LAN firewall 120, which necessitates traffic from the firewall resolver to another resolver, such as ISP 140, over network 130. The latency time of two such round trips may presently be no less than 40 ms compared to 0-3 ms when operating system DNS cache 110 is the source of the resolution. If resolution information is not in the cache of firewall 120 or ISP 140, other intermediate servers 160 may be queried over one or more networks 150. If the hostname is yet to be resolved, authoritative server 170 or main DNS server 180 will be queried and latency will be further increased. Failures, delays and lost packets contribute to accumulated latency that can commonly exceed 1 second or longer. Longer latency times cause discomfort to users of a web browser.
DNS resolution times can be reduced. When DNS resolution occurs for a website, cached results will make future visits to a website quicker. For instance, a web page when first visited may have a portion of its presentation latency attributable to DNS resolution, which could exceed 120 milliseconds. Future visits will get DNS queries from cache at no cost.
User-perceived latency may be reduced through DNS pre-fetching. DNS pre-fetching resolves or fetches a variety of hostnames through the DNS in advance of user activities, anticipating that one of those name resolutions will probably be useful in an upcoming user webpage or hostname request. However, browsers currently do not do DNS pre-fetching for a number of reasons. Engineers have not implemented techniques for DNS pre-fetching in browsers, fearing that the delicate complexity of the network stack would be compromised. Also, engineers have thought that implementations would have to be adapted for each different network application or browser. Further, engineers have worried that any additional network code, processing or complexity prior to a user request would only further increase latency.